home *** CD-ROM | disk | FTP | other *** search
Text File | 1988-07-26 | 10.3 KB | 246 lines | [TEXT/MACA] |
- A Review of THINK’s LightspeedC(TM) 3.0
-
- By Jerry Whitnell
-
- July 8, 1988
-
- Copyright 1988 by Jerry Whitnell
-
- All rights reserved.
-
-
-
- I just received my copy of THINK’s LightspeedC Version 3.0 and after playing
-
- with it for a several hours will attempt to review it. I bought the original
-
- LightspeedC Version 1.0 at the San Francisco MacWorld where it was
-
- introduced, so I have some experience with the product. I will assume you
-
- are familiar with LightspeedC and so will comment only on what's changed
-
- between Version 2.15 and Version 3.00
-
-
-
-
-
- The Packaging
-
-
-
- LightspeedC comes in a real box, unlike the shrink-wrapped manual that
-
- delivered 2.15. Inside are two disks (800K), two manuals and various pieces
-
- of product literature from Symantec. The two manuals are much smaller then
- then the original 8 1/2" by 11" manual. Much of the material is from the original
-
- manual or the 2.03 addendum, but there is also alot of new material as well.
-
- The first manual is the User's Manual and describes both the integrated
-
- Compiler/Editor and the Source-Level Debugger, while the second is dedicated
-
- to the Standard I/O Library supplied for UNIX(TM) compatibility.
-
-
-
-
-
- The Compiler/Editor
-
-
-
- The Editor portion of the compiler appears to be completely unchanged from
-
- the 2.15 version. The compiler, however has many useful changes. The most
-
- obvious are those for the source-level debugger. By setting a checked menu
-
- option (or in the options dialog box) you can tell the compiler to generate
-
- the information the source-level debugger needs to run your program. When
-
- you do this, a little bug appears by the word Name in the project window (NO!
-
- not more bugs in my program!) and each .c file in the list has a little diamond
-
- placed by it's name in the project window. By clicking on the diamond you can
-
- enable or disable symbol table information for that file. This is useful to save
-
- room on your disk, since the symbol table information can double the size of
-
- your project file (270K to almost 600K in my case).
-
-
-
- The Options Dialog has undergone major surgery to reflect changes to the
- compiler. Options are now stored in the Project, rather then in LSC itself, but
- you can specify the default options for any new Project. The options that are
- new since 2.15 are in the area of code generation, precompiled headers and, of
- course, the debugger. You can specify that the generated code use 68020
- instructions, 68881 instructions (or both), in which case the code will only work
- on those processors. There is one precompiled header (called MacHeaders) that
- you can have LightspeedC load before each file. This speeds up the compile since
- LightspeedC doesn't have to reread the .h files from the disk for every file. The
- default MacHeaders comes with a subset of the Macintosh Include files, however
- you can also precompile a new MacHeaders to include the rest of the Macintosh
- header files, the standard I/O Header files or your own common header files.
- Finally, one can specify whether to include the strings in the DATA resource or
- (as in 2.15) include them in a separate STRS resource. Including it in the DATA
- resource allows smaller code since the strings can be referenced off of A5, but
- limits the total strings+data to be 32K. Leaving the strings in the STRS resource
- allows you unlimited strings (but still only 32K of data), but you pay the price of
- larger code. I'll comment on the debugger options when I describe the debugger.
-
-
-
- The Project Type Dialog box has also received many new fields. From it, you can
- now control the MultiFinder flags and default size fields for your application. If
-
- you are building a Desk Accessory or Driver, you can specify you want it
- multi-segment and set the flags as well. Finally for the code resources, you can
- also specify the attributes and whether you want to use the default header or add
- one of your own.
-
-
-
- Other minor changes include "Smart Linking" is now an option during the link
- program phase, selected by a check box in the Save File SF dialog.
-
-
-
- The other feature that didn't change was the inline assembler. A major lack for
- 3.0 is the lack of support for 68020, 68881 and 68851 assembly instructions.
-
- A slightly less major lack is a Print All commands to match the Save All and
- Close All.
-
-
-
- The compiler itself seems to be slower then the 2.15 compiles. Event with the
- source level debugger turned off, the compiler ran 3 to 4 thousand lines a second
- slower then the 2.15 version. Rebuild the project with LSC 3.0 (instead of using
- an imported 2.15) helps alot, but it is still not as fast. Overall compile times
- are faster due to removal of all the extra .h files the MacHeaders replaced. My
- tests showed about a 25% improvement, your mileage may vary.
-
-
-
-
-
- The Debugger
-
-
-
- And now, the moment you all have been waiting for... Once you've selected the
- debugger option and recompiled all your files, all you have to do is select Run and
- up pops the LightspeedC Debugger. But don't forget to load MultiFinder,
- otherwise your program will run without the debugger.
-
-
-
- When you Run your Project, LightspeedC finds and launches both your program and
- the debugger. Control is given to the debugger, and it puts up two windows and
- several menus. The window on the left is the source code window and will
- display the first page of text of your program. The right-hand window is the
- data window, more on it in a moment.
-
-
-
- The text window is a standard text display window with scroll bars, but several
- extra features. Down the left hand side is a black arrow which points at next C
- source statement to be executed. Between the arrow and the left hand side of
- the window are a column of open diamonds. These represent executable
- statements, statements that generate no code (such as declarations and
- comments) have no diamond next to them. In the bottom left-hand corner is the
- name of the current function the text comes from. Across the top are a row of
- square buttons that control program execution. These are Go, Step, In, Out, Trace
- and Stop. Go tells your program to take off and run, Trace steps one source
- statement, In steps into a function (as does Trace), Out will return from the
- current function to the caller and Step steps over function calls, stopping at the
- next source statement after the function. You can go into Auto-step or
- Auto-Trace by holding down the Command or Option key and clicking on the Trace
- or Step buttons. This will cause your program to continue updating the debugger
- window while executing until you click the Stop button or
- Command-Shift-Period.
-
-
-
- You can click on the diamonds (turning them black) which will cause the program
- to stop executing when it reaches the statement the diamond marks. You can set
- as many breakpoints as you want by clicking diamonds. You can also set a
- temporary breakpoint by holding down the Command or Option key when clicking
- the diamond. This temporary breakpoint will be removed when any breakpoint
- (either the temporary or a permanent one) is reached.
-
-
-
- The data window lets you display the value of any C expression except those that
- have side effects in any of several formats. Simple objects such as ints, longs
- and pointers can be displayed as numbers, characters or (for pointers) strings.
- Structs, arrays and unions are identified by indicators (struct, [], and union) and
-
- the address of the object. double clicking on the data portion will bring up a
- separate window that displays the fields of the structure. You can repeat this ad
- nasum or until memory in the debugger runs out. One nice feature is that you can
- case types (just like real C) so you can display data using different types.
- Another nice feature is it knows all the preprocessor symbols as well as the C
- symbols. Finally, by default the values of each expression are updated on entry
- to the debugger. However you can place a lock on an expression which prevents
- the value from being updated. This is useful to watch how a value changes
- because of some operation or function.
-
-
-
- One features combines the data windows and the breakpoint window. By
- selecting a statement in the text window and an expression in the data window
- one can make a conditional breakpoint that breaks only when the expression
- evaluates to non-zero. Otherwise your program keeps executing.
-
-
-
- Finally there is some limited communication between LSC (which is still
- executing) and the debugger. By selecting a menu option in the debugger, you can
- bring up the file you are executing from in a LSC editor window and edit it.
- Similarly, you can select a file in the LSC project and return to the debugger
- bringing it up in the text window. This latter is a clumsy but useful way to set
- breakpoints in a file other then the one you are executing.
-
-
-
- You can (via the Monitor command) also enter low-level debugger such as TMON or
- MACSBUG. LSC still comes with MACSBUG, but they removed the section in the
- manual on it so you're on your own.
-
-
-
- Finally if you fortunate enough to have both a Mac II and a second monitor, you
- optionally tell the debugger to bring up the windows on the second screen.
-
-
-
- All-in-all, I have mixed feelings about the debugger. There are lots of useful
- features in it, but I have lots of nits to pick with the user interface. For
- example, as mentioned above, there is only one text window and to bring up the
- text from other files you must go back to LSC (unless you execute code from that
- file in which case it is automatically displayed in the text window). And while
- multiple data windows are allowed, only the original one can have data entered
- into it. The others only display the fields of structures that you have opened.
- And while there is a Windows menu, the only two windows that you can select
- from it are the two original windows! If you open another to display the fields
- of a structure, it doesn't get added. Get enough windows and things get hard to
- find. Finally, I can't resist playing arm-chair quarterback and wonder why the
- debugger is a separate application and not integrated with the editor/compiler.
- It seems the current design leads to kludges and lots of wasted memory.
-
-
-
- However the system works well together and in spite of the criticisms it does a
- good job of helping debug your programs. And one nice feature is that it is
- guaranteed to make any user of Microsoft's QuickC or Borland's TurboC eat their heart out.
-